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ABSTRACT 


Building  quality  can  be  improved  and  building  cost  reduced  through  more 
effective  computer  utilization  in  design  and  construction.  To  accomplish  these 
objectives  improved  interfaces  are  needed  between  building  project  databases 
and  computer-based  procedures  for  analysis  and  design,  and  between  computer- 
based  engineering  procedures  and  applicable  design  standards.  This  latter  task 
involves  the  Standards  Interface  for  Computer-Aided  Design  (SI/ CAD).  The  SI/ CAD 
is  the  focus  of  the  current  report.  The  SI/CAD  is  shown  to  be  a critical  deter- 
minant of  CAD  system  effectiveness,  particularly  in  the  domain  of  structural 
engineering  design.  This  report  examines  the  hypotheses  that:  (1)  the  ability 

to  easily  maintain  design  standards  data  is  fundamental  to  CAD  system  effective- 
ness; (2)  the  configuration  of  presently  available  computer-aided  structural 
design  (CASD)  system  software  inhibits  efficient  design  standards  data  modifi- 
cation, requiring  costly  maintenance  to  avoid  software  obsolescence  and 
limiting  the  overall  usefulness  of  these  systems;  and  (3)  methods  to  enhance 
the  efficiency  of  criterion  checking  and  standards  data  maintenance  are 
required  to  increase  the  utilization  of  CAD  technology.  Support  for  hypotheses 
(1)  and  (2)  is  developed  from  anecdotal  engineering  experience  and  the  technical 
literature  drawn  principally  from  CASD.  No  evidence  was  found  to  support 
hypothesis  (3). 


KEY  WORDS:  building  codes  and  standards;  building  delivery  process;  building 

design  process;  computer-aided  building  design;  computer-aided  design;  computer 
integrated  construction;  engineering  database  management;  structural  engineering 
computer  programs. 
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1 . INTRODUCTION 


1.1  OBJECTIVE  AND  SCOPE 


Computer-aided  design  (CAD)  soon  will  become  the  ordinary  method  for  engineering 
design.  Today,  use  of  CAD  has  become  commonplace  in  the  development  of  inte- 
grated electronic  circuits,  aircraft  and  automobile  components,  and  other 
machinery.  However,  building  construction  is  a sector  of  the  economy  in  which 
most  of  the  potential  increase  in  productivity  from  the  utilization  of  computers 
has  not  yet  been  realized  [29]. 

The  National  Bureau  of  Standards'  (NBS)  Center  for  Building  Technology  (CBT)  is 
researching  ways  to  improve  building  quality  and  reduce  building  cost  through 
more  effective  computer  utilization  in  design  and  construction.  Pertinent  to 
these  overall  objectives,  CBT  is  seeking  to  improve  information  interfaces: 

„(1)  between  building  project  data  and  the  analysis  and  design  procedures 
employed  by  various  engineering  disciplines,  and  (2)  between  computer-aided 
engineering  procedures  and  applicable  building  design  standards.  This  latter 
task  concerns  a set  of  problems  termed  by  CBT  researchers  the  "Standards  Inter- 
face for  Computer-Aided  Design"  (SI/CAD),  and  comprises  the  focus  of  the 
present  discussion. 

Principal  subjects  of  this  discussion  are  those  technical  problems  arising  from 
the  automation  of  design  checking  procedures.  Checking  procedures  compare 
design  decisions  and  solutions  against  standards  and  other  criteria,  and  are 
common  to  all  design  domains.  CAD  software  systems  typically  expend  consider- 
able computational  effort  and  memory  to  automate  checking  procedures.  These 
procedures  comprise  the  SI/CAD.  In  the  present  treatment  technical  problems 
diminishing  the  efficiency  of  the  SI/CAD  are  explored  within  the  context  of 
structural  engineering  applied  to  the  design  and  construction  of  buildings. 
Specifically,  problems  associated  with  the  execution  of  checking  procedures  in 
computer-aided  structural  design  (CASD)  are  considered  in  detail.  Appendix  A 
overviews  the  building  delivery  and  structural  design  processes  for  readers  not 
already  familiar  with  these  application  settings. 

1.2  THE  STANDARDS  INTERFACE  FOR  COMPUTER-AIDED  DESIGN:  TECHNICAL  PROBLEMS 


1.2.1  Technical  Definition  of  the  Standards  Interface 

Any  discussion  of  CASD  requires  consideration  of  the  relationship  between 
generic  standards  and  project-specific  design  descriptions:  the  SI/CAD.  What 

is  the  SI/ CAD,  and  why  is  it  a determinant  of  CASD  system  effectiveness? 

The  essential  process  occurring  at  the  standards  interface  is  criterion  checking. 
Criteria  include  provisions  of  design  standards  (e.g.,  maximum  allowable  shear 
stress  in  a beam)  as  well  as  user-defined  requirements  (e.g.,  minimum  allowable 
ceiling  height).  During  this  process,  individual  elements  of  a candidate  struc- 
tural design  solution,  determined  on  the  basis  of  their  ability  to  withstand 
stresses  resulting  from  anticipated  project-specific  loading  and  environmental 
conditions,  are  checked  against  generic  criteria  stipulating  required  structural 
qualities.  A technical  term  for  criterion  checking  in  CASD  is  "constraint 
processing ." 
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1.2.2  The  Standards  Interface  as  a Critical  Determinant  of  CASD  System 
Effectiveness:  Hypotheses 

Three  hypotheses  concerning  the  role  of  SI/CAD  as  a determinant  of  CASD  system 
effectiveness  are  considered:  (1)  the  ability  to  easily  maintain  design  stan- 

dards data  is  a fundamental  determinant  of  CASD  system  effectiveness;  (2)  the 
configuration  of  presently  available  CASD  system  software  inhibits  efficient 
design  standards  data  modification,  requiring  costly  maintenance  to  avoid  soft- 
ware obsolescence,  and  limiting  the  overall  usefulness  of  these  systems;  and 
(3)  methods  to  enhance  the  efficiency  of  criterion  checking  and  the  maintenance 
of  standards  data  are  required  to  increase  the  utilization  of  CASD  technology. 

These  hypotheses  arise  from  a number  of  practical  engineering  concerns, 
including:  (1)  the  costs  of  design  software  downtime,  (2)  the  risks  of  check- 

ing designs  against  obsolete  or  even  incorrect  standards,  (3)  the  costs  of 
being  unable  to  use  a desirable  CASD  software  system  because  the  system  does 
not  check  designs  against  standards  applicable  to  the  problem  at  hand,  (4)  the 
costs  of  developing  reasonable  engineering  design  standards. 

The  ability  to  maintain  a design  standards  database  rapidly  and  at  low  cost 
provides  a measure  of  a CASD  system's  cost-effectiveness,  particularly  when  the 
costs  associated  with  software  "downtime”  (required  during  standards  database 
maintenance)  are  considered.  For  the  most  part,  commercially  available  CASD 
software  systems  provide  relatively  inefficient  mechanisms  for  maintaining 
design  standards  databases  [53].  For  example,  while  tables  of  structural  steel 
shapes  may  be  treated  as  data  that  can  be  quickly  replaced  by  updated  tables, 
design  criteria  and  algorithms  for  checking  instances  against  the  criteria 
typically  are  "hard-coded"  within  CASD  software  systems.  Thus,  modifications 
to  criteria  and  checking  algorithms  require  altering  system  code,  and  this 
results  in  software  downtime. 

Building  code  design  provisions  tend  to  be  diverse  and  unstable.  Provisions 
often  vary  across  geographic  boundaries,  and  in  addition,  they  undergo  change 
periodically  (three  year  cycles  are  typical).  But  the  practice  of  structural 
engineering  demands  knowledge  of,  and  adherence  to,  design  standards  which  are 
both  up-to-date  and  applicable  to  a given  task  and  jurisdiction.  Because  CASD 
software  programs  provide  no  systematic  means  for  maintaining  design  standards 
data,  and  because  these  standards  change  periodically,  increases  in  design 
productivity  usually  assumed  to  result  from  CASD  utilization  may  be  called 
into  question.  Refer  also  to  Appendix  sections  A.l  and  A. 3. 

Another  kind  of  problem  arises  in  connection  with  the  standards  development 
process.  Standards  writers  typically  are  unable  to  evaluate  potential  costs 
associated  with  new  or  modified  provisions,  primarily  because  there  exist  no 
mechanisms  for  simulating  design  performance  under  alternative  versions  of  a 
standard.  Standards  writers  could  more  effectively  determine  the  impact  of 
their  decisions  by  developing  alternative  standards  databases,  employing  each 
In  the  automated  design  of  a structure,  and  then  comparing  design  results 
produced  under  each  version  of  the  standard.  However,  no  commercially  available 
CASD  software  system  presently  permits  such  an  application. 
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For  these  reasons,  important  changes  in  the  conceptualization  of  the  standards 
interface  seem  warranted.  In  particular,  research  is  needed  to:  (1)  develop  a 

CASD  system  design  philosophy  which  separates  building  design  criteria  and 
checking  procedures  from  analysis  and  other  components  of  CASD  software  systems, 
and  which  treats  criteria  and  instructions  for  checking  as  data  applied  at  sys- 
tem execution  time;  (2)  develop  an  appropriate  algorithm  for  constraint 
processing,  and  (3)  develop  standards  for  configuring  design  criteria  databases. 

Chapter  2 provides  in-depth  reviews  of  ICES/STRUDL^-  and  GENESYS^,  two  of  the 
most  widely  used  automated  structural  design  software  packages.  The  purpose  of 
these  reviews  is  to  illustrate  technical  problems  typically  associated  with  the 
standards  interface.  The  reader  may  obtain  further  background  in  the  state-of- 
the-art  of  integrated  computer-aided  design  systems  (ICAD)  and  CASD  by  referring 
to  Appendix  section  B.3. 


1/  Integrated  Civil  Engineering  System/ STRuctural  Design  Language. 
Id  GENeral  Engineering  SYStem. 
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2.  CURRENT  IMPLEMENTATIONS  OF  THE  STANDARDS  INTERFACE:  SOME  EXAMPLES 

ILLUSTRATING  KEY  PROBLEMS 

2.1  INTEGRATED  CIVIL  ENGINEERING  SYSTEM/STRUCTURAL  DESIGN  LANGUAGE: 
ICES/ STRUDL 


2.1.1  Overview 

STRUDL  is  an  engineering  tool  which  automates  complex  and  time  consuming 
structural  analysis  and  design  tasks.  STRUDL  is  based  on  the  concepts  that  the 
design  process  is  an  iterative  sequence  of  decisionmaking  and  computational 
tasks  which  are  usually  impossible  to  sequence  a priori,  and  that  any  attempt 
to  limit  the  designer  to  a single  prescribed  design  strategy  is  undesirable. 

To  implement  these  concepts,  STRUDL  permits  the  designer  to  configure  any 
sequence  of  operations  to  suit  the  demands  of  an  individual  design  problem 
[47]. 

The  user  communicates  with  STRUDL  by  means  of  a problem  oriented  language  (POL) , 
permitting  the  designer  to  structure  English-like  command  phrases  which  control 
the  flow  of  project  information  and  engineering  tasks.  Principal  components  of 
STRUDL  available  to  the  structural  designer  include  modules  corresponding  to 
the  desired  analysis  mode  (e.g.,  frame,  finite  element),  modules  permitting  pro- 
ject data  input  (e.g.,  geometry,  loads,  desired  properties),  modules  enabling 
the  production  of  various  STRUDL  reports,  and  capabilities  for  invoking  STRUDL' s 
member  selection  and  code-check  functions.  At  any  point  during  the  design  pro- 
cess, the  engineer  may  call  upon  a STRUDL  processor  (in  any  logical  sequence) 
to  conduct  a particular  form  of  analysis,  modify  current  geometric  or  loading 
configurations,  select  structural  members  from  appropriate  tables,  or  conduct 
code  checks  on  the  current  design. 

2.1.2  Implementation  of  the  Standards  Interface 

STRUDL  supports  structural  design  through  its  code-check,  parameter  and 
geometric  constraint  processing,  member  selection,  and  design  summary  output 
capabilities.  The  system's  code-checking  and  constraint  processing  features 
are  of  special  interest  here.  The  commercially  available  versions  of  STRUDL 
perform  generalized  steel  frame  design  in  accordance  with  versions  of  the 
American  Institute  for  Steel  Construction  (AISC)  specifications,  and  with 
Canadian,  British  and  other  foreign  specifications.  Specifications  for  the 
design  of  off-shore  drilling  platforms,  steel  transmission  towers,  and  other 
special  structures  also  are  available  within  these  versions  of  STRUDL.  The 
design  of  concrete  structures  is  performed  in  accordance  with  applicable 
standards  of  the  American  Concrete  Institute  (ACI). 

When  initiating  a design  session,  the  engineer  declares  the  desired  design 
specification  by  invoking  a single  STRUDL  command.  During  the  session,  the 
engineer  may  invoke  an  alternative  specification  contained  within  STRUDL  (e.g., 
AISC-1978  may  be  substituted  for  AISC-1969),  and  the  results  of  design  checks 
based  on  each  specification  can  be  readily  compared.  Depending  upon  specific 
options  requested  by  the  user,  code-check  summary  output  may  include: 
controlling  code  provision  values  for  critical  design  loading  conditions  at 
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critical  sections  along  members,  and  actual  and  allowable  values  of  all  design 
code  provisions  and  parameters  for  each  active  design  loading  condition  at 
every  section  along  a member  [32,  p.  25]. 

In  general  standards  consist  of  (1)  tables  of  structural  shapes  and  members 
(in  the  case  of  steel  frame  design),  (2)  specifications  of  minimum  requirements, 
and  (3)  rules  for  determining  whether  a selected  (or  designed)  member  conforms 
with  applicable  criteria.  Each  must  be  represented  within  the  CASD  environment. 
Structural  tables  are  contained  by  STRUDL  as  data,  and  these  may  be  updated  or 
modified  with  relative  ease.  Specifications  of  minimum  requirements  and  rules 
for  determining  design  conformance,  however,  are  not  treated  as  data,  but 
rather  are  "hard-coded”  within  STRUDL’ s program  logic.  As  a result,  periodic 
changes  in  criteria  and/or  algorithms  for  measuring  design  conformance,  as  may 
be  promulgated  by  standards-writing  organizations  or  building  code  jurisdica- 
rions,  require  modifications  to  STRUDL  software  modules.  Thus,  while  STRUDL 
provides  numerous  capabilities  useful  to  the  structural  engineer,  and  while 
the  program's  application  is  likely  to  noticeably  improve  design  productivity, 
it  remains  incumbent  upon  the  user  to  ascertain  that  design  standards  employed 
by  STRUDL  during  code-checking  are  current  and  valid  for  the  project  at  hand. 

The  commercial  versions  of  STRUDL  do  not  permit  the  Individual  user  to  update 
or  otherwise  modify  portions  of  design  standards,  nor  to  "swap-in"  proposed  new 
versions  of  standards  for  purposes  of  comparative  analysis.  For  this  reason 
STRUDL  in  its  present  form  would  not  be  an  effective  aid  to  standards  develop- 
ment and  evaluation  (purposes  for  which  the  program  was  never  intended  by  its 
developers) . 

2.1.3  Availability 

At  present,  there  are  two  versions  of  STRUDL  supported  for  widespread  commercial 
use.  The  Georgia  Institute  of  Technology's  GT/ICES  System  Laboratory  has 
developed  and  supported  GT/ICES  and  GT/STRUDL  [19,  32,  33].  GT/STRUDL  may  be 
implemented  on  user-owned  Digital  Equipment  Corporation  (DEC)  VAX  or  Control 
Data  Corporation  (CDC)  CYBER  machines,  and  it  also  may  be  accessed  on  a conver- 
sational time-share  basis  through  CDC.  A second  version.  Time  Sharing  Option 
(TSO)  STRUDL  has  been  implemented  in  an  IBM  environment,  and  is  available  com- 
mercially on  a time-share  basis  through  the  McDonnell  Douglas  Automation 
Company  [63]. 

2.2  GENERAL  ENGINEERING  SYSTEM:  THE  GENESYS  SOFTWARE  LIBRARY 


2.2.1  Overview 

GENESYS,  Ltd.,  a software  development  organization  in  the  United  Kingdom, 
provides  an  extensive  collection  of  programs  to  support  the  engineering  design 
and  construction  of  buildings  and  other  structures.  Many  of  the  products  con- 
tained in  the  GENESYS  library  are  versions  of  programs  originally  developed  at 
universities  and  research  laboratories.  Other  programs  are  proprietary  to 
GENESYS,  Ltd. 

For  the  most  part,  GENESYS  programs  are  configured  into  "suites"  providing 
specialized  engineering  capabilities.  Individual  suites  may  be  obtained  for 
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structural  analysis,  concrete  design  and  detailing,  structural  steelwork, 
ground  engineering,  etc.  Each  suite  contains  all  the  facilities  necessary  for 
developing  and  maintaining  a project  database,  providing  user-machine  communi- 
cations (including  tabular  and  graphic  output)  and  conducting  applicable  analy- 
sis, design,  and  checking  tasks.  However,  a single  data  model  is  not  common  to 
all  suites. 

As  with  STRUDL,  the  user  communicates  with  a GENESYS  Suite  through  a POL. 

Sample  commands  from  a suite  developed  for  designing  reinforced  concrete 
structures  are: 

DEFINE  GEOMETRY  USING  * BASIC-GRIDS* ,' GRIDS ',' LEVELS ' ; 

SET  MATERIAL  PROPERTIES  ' STEEL ’,' CONCRETE ’ ; and 
COLUMN  DESIGN  AND  DETAIL  OF  GROUP  ’TYPED'. 

This  last  command  causes  a column  element  to  be  designed,  in  accordance  with 
applicable  design  standards  (in  this  case  the  British  Code  of  Practice  110), 
and  a detailed  drawing  of  the  column  (illustrating  the  location  of  reinforce- 
ment) to  be  generated.  Unlike  GT/STRUDL  and  TSO/ STRUDL,  however,  GENESYS 
suites  may  be  used  in  batch  mode  only.  Consequently,  the  GENESYS  user  is  more 
apt  to  utilize  the  computer  for  automated  production  design,  detailing,  and 
drafting,  while  the  STRUDL  user  is  likely  to  use  the  system  as  an  interactive 
aid  to  design  decisionmaking. 

2.2.2  Implementation  of  the  Standards  Interface 

As  with  various  versions  of  STRUDL,  GENESYS  supports  structural  design  through 
code-checking  and  parameter  and  constraint  processing.  Moreover,  GENESYS  also 
contains  specifications  of  minimum  requirements  and  rules  for  determining 
design  conformance  (provided  by  applicable  code  provisions)  as  "hard-code" 
within  a design  suite's  program  logic.  Thus,  to  update  or  maintain  design 
standards,  to  design  under  an  alternative  version  of  a standard,  or  to  employ 
GENESYS  in  situations  requiring  other  than  the  British  Codes  of  Practice  each 
necessitates  fundamental  software  modification.  For  these  reasons,  GENESYS 
seems  best  suited  to  local,  volume-oriented  engineering  production  work,  and 
appears  largely  ineffective  as  a tool  to  assist  standards  development  and 
evaluation  (the  latter  tasks  are  not  intended  by  GENESYS,  Ltd.).  The  inability 
to  link  versions  of  American  Standards  easily  is  a principal  deterent  to  the 
system's  use  in  the  United  States. 

2.3  ADDITIONAL  CONSIDERATIONS 


STRUDL  and  GENESYS  are  modern  software  systems  for  automating  time  consuming 
engineering  tasks.  The  commercially  available  design  systems  are  specifically 
intended  to  automate  certain  aspects  of  the  structural  engineer's  work,  most 
notably  the  proportioning  and  selection  of  frame  members,  in  addition  to 
analyzing  structures.  These  systems  also  maintain  project  data,  although  this 
capability  typically  is  limited  in  utility  by  the  local  requirements  of  any 
individual  software  system.  Thus,  data  describing  a building's  frame  geometry 
developed  using  STRUDL  and  stored  electronically  under  a STRUDL- imposed  data 
format  may  be  quite  difficult — and  costly — to  transfer  to  some  other  software 
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system  used  by  a mechanical  engineer  or  interior  space  planner  requiring 
geometric  data  describing  the  same  project.  The  concept  that  data  should  be 
developed  and  stored  in  a manner  making  them  accessible  to  the  numerous  and 
diverse  participants  of  a project  has  led  to  consideration  of  Integrated  CAD 
(ICAD)  technology.  This  subject  has  been  explored  in  substantial  depth  by 
Rehak  and  Lopez  [53],  and  is  overviewed  in  Appendix  sections  A.l,  B.1.1,  and 
B.2  of  the  present  report. 


3.  RECOMMENDED  APPROACH  FOR  RESOLVING  THE  STANDARDS  INTERFACE:  CURRENT 

RESEARCH  DIRECTIONS 

3.1  INTRODUCTION 


Researchers  at  CBT  are  working  to  determine  standard  measures,  test  methods, 
recommended  practices,  and  performance  criteria  for  algorithms  and  data  struc- 
tures applicable  to  the  SI/CAD.  CBT  is  particularly  concerned  with  practices 
pertaining  to  automated  constraint  processing  and  design  standards  representa- 
tion. These  immediate  concerns  are  consistent  with  the  broader  research  goal 
of  facilitating  development  of  cost  effective  computer  technology  for  building 
design  and  construction. 

In  recent  years  CBT  investigators  and  other  workers  have  developed  a number  of 
computer-based  techniques  that  can  be  used  to  perform  automated  constraint 
processing  for  engineering  structures  [31,  38,  66].  There  have  been  advances 
in  the  areas  of  computerized  standards  processing  [35,  62],  engineering  data- 
base management,  and  automated  structural  analysis.  Each  of  these  areas  has 
developed  via  relatively  separate  research  paths,  and  it  now  is  possible  to 
integrate  these  technologies  in  the  solution  of  problems  associated  with  effi- 
cient constraint  processing  in  engineering  design.  Essential  to  the  evolution 
and  implementation  of  constraint  processing  technology  is  the  representation  of 
building  codes  and  standards  in  an  appropriate  computer-processible  form. 

Toward  this  end,  NBS  has  developed  the  Standards  Analysis,  Synthesis,  and  Expres- 
sion (SASE)  software  package,  a computer  program  based  on  a systematic  methodo- 
logy for  machine-coding  provisions  of  standards  and  the  hierarchical  relation- 
ships among  provisions  [22,  23,  34,  35,  62].  Technical  approaches  for  resolving 
the  standards  interface,  emphasizing  the  study  of  constraint  processing  and 
standards  representation  are  discussed  below. 

3.2  CONSTRAINT  PROCESSING 


Although  automated  constraint  processing  [66]  and  supporting  data  structures 
[31]  were  analyzed  in  considerable  depth  more  than  a decade  ago,  no  constraint 
processor  based  on  these  concepts  has  since  been  developed  and  implemented 
either  commercially  or  on  a research  basis.  CBT  is  currently  seeking  to 
develop  performance  requirements  for  such  a device.  The  core  of  this  research 
effort  is  CBT’s  experimental  CASD  software,  based  on  the  POLO/FINITE  system. 

POLO  provides  database  management  and  language  development  capabilities  needed 
to  support  CASD  system  configuration.  FINITE  provides  an  initial  structural 
analysis  capability  for  a research  CASD  system.  The  immediate  goals  of  CBT 
investigators  are  to  implement  member  sizing,  constraint  processing,  and  optim- 
ization algorithms  under  POLO,  and  then  exercise  the  experimental  CASD  software 
system  to  determine  useful  performance  requirements  for  constraint  processor 
design.  Technical  objectives  of  CBT’s  constraint  processing  research  are  to 
develop  performance  requirements  for  algorithms  designed  to:  (1)  reference 
design  standards  as  external  data  by  commercial  CASD  systems,  (2)  interrelate 
standards  criteria,  design  data,  and  constraints,  (3)  determine  the  correct, 
and  most  efficient,  sequence  of  checks  under  given  design  conditions,  and 
(4)  determine  the  status  of  constraints  during  the  design  process,  using  these 
data  to  guide  design  optimization.  A detailed  technical  treatment  of  constraint 
processing  is  given  in  appendix  section  B.1.2  of  this  report. 
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3.2  STANDARDS  REPRESENTATION 


Pioneering  work  by  Fenves  [20]  on  modeling  standards  led  to  the  concepts  that: 
(1)  individual  provisions  of  a standard  could  be  efficiently  and  advantageously 
modeled  by  decision  logic  tables  which  explicitly  reveal  rules  linking  condi- 
tions with  actions,  and  (2)  interrelationships  among  provisions  of  a standard 
could  be  modeled  by  information  networks  which  systematically  organize  provi- 
sions according  to  their  relative  precedence  (i.e.,  their  links  to  "dependent" 
and  "ingredient"  provisions).  This  overall  approach  has  since  been  expanded  by 
Harris  and  Wright  [35]  to  include  complex  organizational  aspects  of  standards 
documents.  Moreover,  it  has  been  used  to  model  specific  standards,  including 
the  Applied  Technology  Council's  Tentative  Seismic  Standard  [34],  the  American 
Institute  of  Steel  Construction  Specification  [24,  26]  and  the  American 
Concrete  Institute’s  Building  Code  for  Reinforced  Concrete  [51]. 

Beyond  modeling  standards  to  systematically  examine  their  clarity,  consistency, 
and  completeness,  Goel  and  Fenves  [31]  and  Fenves  [21]  demonstrated  that  repre- 
sentations of  standards  consisting  of  networks  of  decision  tables  are  appli- 
cable to  constraint  processing  procedures.  Following  from  this  work  CBT 
researchers,  collaborating  with  other  workers,  have  developed  a technology  for 
computerencoding  the  contents  of  standards  [62].  The  Standards  Analysis, 
Synthesis,  and  Expression  (SASE)  software  package  was  initially  developed  to 
support  the  analysis,  formulation,  and  expression  of  standards,  as  an  aid  to 
the  standards  writing  community.  The  system  permits:  (1)  the  coding  of  a 

complete  standard  in  a single  database,  (2)  the  analysis  of  provisions  to 
check  for  clarity  and  completeness,  (3)  the  modeling  and  evaluation  of  rela- 
tions among  provisions  of  a standard,  and  (4)  the  formulation  of  alternative 
organizations  of  a standard's  contents. 

Because  decision  tables  (the  basic  mode  for  representing  individual  provisions 
of  a standard  under  the  SASE  model)  are  readily  processed  into  computer  program 
code  [42],  standards  databases  prepared  using  SASE  are  readily  adaptable  to  a 
form  required  for  automated  constraint  processing.  CBT's  ongoing  research  in 
the  interrelated  areas  of  constraint  processing  and  standards  representation, 
therefore,  shall  seek  to  determine  performance  requirements  for  algorithms 
which  express  the  contents  and  organization  of  standards  in  a form  permitting 
generic  standards  data  to  be  conveniently  linked  to  CASD  systems  at  the  con- 
straint processing  juncture.  In  this  way,  CBT  expects  to  play  a key  role  in 
improving  the  SI/CAD,  and  thereby  in  helping  to  remove  known  impediments  to  the 
effective  utilization  of  CASD  technology. 
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4.  CONCLUDING  REMARKS 


4.1  REVIEW  OF  THE  HYPOTHESIS 


The  SI/ CAD  has  been  defined  as  the  juncture  between  standards  data  which  are 
generic,  and  design  descriptions  which  are  project-specific.  On  a conceptual 
level  the  SI/CAD  involves  the  nature  of  interrelationships  between  data  describ- 
ing a proposed  (or  existing)  structure  and  those  stipulating  the  structure's 
required  qualities.  On  a working  level  the  SI/CAD  involves  the  implementation 
of  algorithms  for  constraint  processing,  and  thus  is  concerned  with  criterion 
checking  employing  procedures  for  checking  individual  elements  of  a candidate 
design  solution  against  generic  criteria  found  in  regulatory  documents  and 
project  specifications.  CBT  researchers  believe  the  SI/ CAD  to  be  a critical 
determinant  of  CASD  system  effectiveness,  and  on  the  basis  of  practical  engi- 
neering concerns  have  hypothesized  that:  (1)  the  ability  to  easily  maintain 

design  standards  data  is  fundamental  to  CASD  system  effectiveness;  (2)  the  con- 
figuration of  presently  available  CASD  system  software  inhibits  efficient  design 
standards  data  modification,  requiring  costly  maintenance  to  avoid  software 
obsolescence  and  limiting  the  overall  usefulness  of  these  systems;  and 
(3)  methods  to  enhance  the  efficiency  of  criterion  checking  and  standards  data 
maintenance  are  required  to  increase  the  utilization  of  CASD  technology. 

Hypothesis  (1)  is  supported  by  anecdotal  data  from  professional  engineering 
practice  suggesting  general  concern  for  design  software  which  is  either  obsolete 
(i.e.,  checks  design  instances  against  outdated  standards  criteria)  or  is  too 
limited  in  the  range  of  standards  and  code  criteria  available  for  checking. 

These  anecdotal  data  also  suggest  frustration  on  the  part  of  some  engineering 
practitioners,  who  find  the  task  of  updating  or  modifying  in-house  design  soft- 
ware to  be  impractical,  beyond  their  own  technical  capabilities  or  too  costly. 

On  the  other  hand,  computer  service  bureaus  offering  CASD  packages  to  designers 
on  a time  share  basis,  and  very  large  architecture/engineering  firms  capable  of 
maintaining  a knowledgeable  support  staff,  seem  reasonably  well  equipped — and 
willing — to  maintain  CASD  programs,  even  though  this  occasionally  requires 
costly  reprogramming,  debugging,  and  testing. 

The  current  review  of  available  CASD  software  also  provides  support  for 
hypothesis  (2).  The  facts  that  the  available  systems  incorporate  standards 
criteria  and  checking  algorithms  as  "hard  code,"  and  that  the  hard  coding  of 
standards  data  is  one  cause  of  high  CASD  software  maintenance  costs,  were 
explored  in  this  report  by  reference  to  two  systems  in  widespread  commercial 
use:  ICES/ STRUDL  in  the  United  States  and  GENESYS  in  the  United  Kingdom. 

Because  large-scale  investments  in  CASD  software  can  often  lead  to  frustrations 
associated  with  maintaining  these  systems,  it  has  seemed  reasonable  to  assume 
that  hitherto  undeveloped  methods  to  enhance  the  efficiency  of  constraint 
processing  and  the  maintainability  of  standards  data  are  required  to  increase 
the  utilization  of  CASD  technology  by  the  structural  engineering  community. 
However,  CBT  investigators  have  found  no  direct  evidence  to  define  a relation- 
ship between  the  effective  resolution  of  the  SI/CAD  and  CASD  technology  usage 
(hypothesis  3). 
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CBT's  immediate  objective  is  to  mitigate  certain  important  technical 
deficiencies  of  computer-based  structural  design  tools,  most  notably  those 
involving  constraint  processing  and  standards  representation  within  CASD  soft- 
ware systems.  In  the  long  range,  however,  CBT  seeks  to  improve  the  overall 
efficiency  of  building  delivery  by  formulating  performance  requirements  for  the 
computer-based  integration  of  the  entire  building  delivery  process.  To  provide 
an  overall  framework  for  CBT's  current  and  planned  research  on  the  SI/CAD,  and 
to  place  SI/CAD  research  in  the  proper  perspective,  a brief  exploration  of 
"computer-integrated  construction"  and  of  the  role  of  NBS  in  this  important 
area  is  provided  in  Appendix  C of  the  current  report. 

4.2  SUMMARY  AND  CONCLUSIONS 


In  little  more  than  a decade,  CAD  system  development  has  become  big  business. 
Properly  conceived  and  utilized,  CAD  systems  have  considerable  potential  for 
improving  the  quality  and  reducing  the  cost  of  buildings.  Incorrectly  con- 
ceived and  implemented,  however,  CAD  and  particularly  CASD  may  create  new  and 
very  complex  problems.  Of  central  concern  are  potential  problems  surrounding 
algorithms  for  checking  designs  against  criteria  derived  from  building  codes 
and  standards.  At  present,  CASD  system  configurations  frustrate  the  main- 
tenance of  internally  stored  standards  data.  Moreover,  lacking  a general 
model  for  standards  representation,  it  is  possible  that  a single  standard  may 
be  interpreted  and  implemented  differently  within  different  software  systems. 

As  a result  of  such  conditions,  building  designs  developed  using  CASD  software 
may  not  necessarily  conform  with  the  latest  versions  of  applicable  standards, 
and  in  some  instances  their  validity  may  even  be  called  into  question. 

CBT  is  seeking  to  minimize  the  potential  for  these  and  similar  problems,  and 
thereby  to  assist  industry  in  its  development  of  useful  and  effective  design 
tools.  To  accomplish  this,  investigators  are  seeking  to:  (1)  improve  inter- 

faces between  building  project  databases  and  procedures  for  analysis  and  design 
employed  by  various  engineering  disciplines,  and  (2)  define  the  interface 
between  computer-based  engineering  procedures  and  applicable  building  design 
standards.  This  latter  task  concerns  a set  of  problems  termed  the  Standards 
Interface  for  Computer-Aided  Design,  or  SI/ CAD.  Technical  problems  associated 
with  SI/CAD  implementation  are  of  immediate  concern  to  CBT  researchers,  and 
comprise  the  central  focus  of  this  report.  To  place  the  SI/CAD  in  the  proper 
perspective,  the  report  also  introduces  the  wider  concept  of  computer-integrated 
construction,  and  explores  the  appropriate  role  of  NBS  in  this  area  of  national 
concern. 

A number  of  hypotheses  were  advanced  concerning  relationships  between  the 
effective  resolution  of  the  SI/CAD,  the  ability  to  efficiently  maintain  stan- 
dards databases,  and  CAD  usage  in  the  building  community.  These  hypotheses 
were  partially  supported  by  anecdotal  data  from  engineering  experience,  and 
from  a review  of  the  CASD  literature. 

During  recent  years  CBT  has  become  active  in  two  interrelated  areas  of  research 
essential  to  the  resolution  of  the  SI/CAD.  These  are  automated  constraint  pro- 
cessing and  computer-based  stahdards  representation.  With  the  implementation 
during  1982  of  the  Standards  Analysis,  Synthesis  and  Expression  software 
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package,  it  now  is  possible  to  machine-code  provisions  of  standards  and  the 
hierarchical  relationships  among  these  provisions.  The  link  between  standards 
representation  and  constraint  processing  involves  the  incorporation  of  rules 
contained  within  individual  provisions  of  a standard,  and  of  the  hierarchical 
structure  of  provisions,  into  executable  program  logic.  This  link  is  studied 
in  a current  project. 

In  summary,  it  is  widely  felt  that  significant  gains  in  building  delivery 
productivity  and  building  quality  may  be  derived  from  increased  utilization  of 
computer  technology  in  various  segments  of  the  building  industry.  Within  its 
mission  as  the  nation's  central  engineering  and  measurement  laboratory,  NBS 
is  seeking  to  characterize  critical  aspects  of  design  and  construction  automa- 
tion, develop  measures  of  design  and  construction  technology  performance,  and 
specify  effective  performance  requirements  necessary  in  the  manufacture  and 
procurement  of  such  technologies.  Within  this  framework,  CBT  researchers  are 
exploring  new  approaches  to  automated  structural  design  and  are  considering 
ways  of  integrating  by  computer  the  many  diverse  construction  tasks. 
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APPENDIX  A:  A BRIEF  OVERVIEW  OF  THE  BUILDING  DELIVERY  AND  STRUCTURAL  DESIGN 

PROCESSES 

A. 1 THE  BUILDING  DELIVERY  PROCESS 

The  process  of  producing  a complete  building  differs  substantially  from  that 
of  manufacturing  a discrete  machine  (or  even  building)  component.  The  produc- 
tion of  a building  involves  a far  larger  network  of  tasks  that  often  are  more 
complex,  diverse,  and  geographically  distributed  than  those  involved  in  the 
production  of  discrete  industrial'  conponents  (see  figure  A.l).  In  addition, 
criteria  for  building  design  and  construction  tend  to  be  considerably  more 
diverse  and  subject  to  change  than  those  governing  the  design  and  manufacture 
of  machine  components.  Finally,  building  industry  participants  typically  are 
unable  to  invest  capital  at  levels  necessary  to  support  large-scale  process 
automation  and  integration.  Taken  together r,  these  factors  thwart  some  gains 
In  building  industry  productivity  which  might  be  obtained  through  the  effective 
use  of  computer  technology.  The  special  problems  of  building  process  com- 
plexity and  design  criteria  changeability  now  may  be  described  in  greater 
detail.  ? 

Complexity  of  the  building  delivery  process.  The  complex  nature  of  the  building 
process  arises,  in  large  part,  from  the  wide  diversity  of  approaches  for  crea- 
ting and  communicating  design  data,  and  from  the  fragmentation  of  the  building 
enterprise  into  numerous  distinct  and  often  widely  distributed  organizations. 

The  creation  of  a single  building  typically  requires  the  coordinated  efforts  of 
numerous  and  diverse  participants,  including  architects,  space  planners,  engi- 
neers of  various  kinds,  regulatory  officials,  construction  managers,  building 
contractors,  and  others.  However,  there  presently  exists  no  shared  model  for 
creating  and  communicating  design  information  among  these  participants.  As  a 
result,  much  of  the  data  describing  a project  often  is  either  redundant  or 
conflicting.  For  example,  both  the  structural  engineer  and  the  space  planner 
play  a vital  role  in  the  building  delivery  process.  In  many  ways,  moreover, 
decisions  made  by  either  of  these  professionals  affect  those  of  the  other. 
Drawings  prepared  by  the  space  planner'1  which  illustrate  the  location  of  columns 
and  other  structural  elements  of  a building  <^upl icates ^he  efforts  of  the  struc- 
tural engineer,  who  has  also  prepared  drawings  locating  such  elements.  If  the 
space  planner  incorrectly  locates  on  a space  plan  drawing  even  one  structural 
element,  then  subsequent  space  plan  data  will  conflict  with  structural  data 
describing  the  same  building.  Such  conflicts  are  common  throughout  the  building 
delivery  process,  and  are  often  very'  costly  to  isolate  and  correct. 

Although  many  individual  participants  in  the  building  process  presently  employ 
computers  for  specific  tasks  (e.g.,  benefit/cost  analysis,  structural  analysis 
and  design,  space  planning),  computer-based  task  integration  and  distribution 
among  participants  has  not  yet  been  achieved  in  the  building  industry.  An 
important  reason  for  this  is  the  fragmentation  of  building  delivery  tasks  among, 
for  the  most  part,  independent  small  businesses  and  specialists.  Thus,  to 
succeed  in  the  building  marketplace,  providers  of  software  for  various  analysis 
and  design  tasks  have  tended  to  limit  their  offerings  to  specialized,  task- 
specific  products  executable  on  computing  machinery  most  likely  to  be  found  in 
architectural,  engineering,  and  construction  firms.  This  market  environment 
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Figure  A.l*  A simplified  overview  of  the  Building  delivery  process 


provides  little  encouragement  for  computer-based  building  delivery  task 
integration  and  distribution.  As  a result,  it  is  generally  not  possible  at 
present  for  data  created  on,  say,  the  architect's  desktop  microcomputer  to  be 
transported  to — and  processed  by — the  structural  engineer's  time-share  system. 

In  the  present  context  Integrated  CAD  (ICAD)  connotes  the  ability  of  diverse 
participants  in  a single  building  project  to  create  and  manipulate  data,  and 
to  share  these  data  through  a common  project  database.  Distributed-Integrated 
CAD  (DICAD)  extends  this  concept,  distributing  terminals  and/or  computers  among 
project  participants  who  are  geographically  separated,  employing  specialized 
software,  using  computing  machinery  of  different  configuration  or  manufacture, 
but  are  interacting  through  a common  project  database.  Although  DICAD  is  not 
currently  practiced  in  the  building  industry,  very  limited  forms  of  ICAD  do 
exist  today.  Thus,  a multidisciplinary  architectural  and  engineering  firm 
typically  assembles  a given  project  team  from  all  disciplines  needed  to  design 
the  structure  and  prepare  the  contract  documents,  whether  or  not  any  of  the 
tasks  have  been  computerized.  A number  of  such  firms  have  already  developed 
their  own  "in  house"  ICAD  capability,  enabling  various  participants  in  a given 
building  project  to  create  and  manipulate  project  data  residing  in  a central 
project  database  [13,  27,  60]. 

Diversity  and  Instability  of  Design  Criteria.  Another  important  impediment  to 
the  widespread  application  of  computers  by  the  building  industry  concerns  the 
diversity  and  rapid  change  of  design  criteria  affecting  building  projects. 

Design  criteria  may  vary  as  a function  of  geographic,  jurisdictional,  techno- 
logical, social,  and  other  considerations.  They  also  change  over  time.  For 
example,  design  criteria  effecting  the  thermal  characteristics  of  a building 
vary  from  one  geographic  region  to  another.  Similarly,  criteria  stipulated  by 
local  building  codes  often  vary  from  one  jurisdiction  to  another.  In  many 
instances,  moreover,  criteria  may  be  interpreted  differently  by  various  partic- 
ipants in  the  building  delivery  process.  Thus,  a criterion  governing  ceiling 
height  connotes  spatial  quality  to  the  architect  and  space  planner,  while  indi- 
cating minimum  available  clearances  to  the  mechanical  systems  designer. 

Finally,  many  design  criteria  vary  over  time,  as  when  the  social  or  economic 
conditions  affecting  a project  change  during  the  design  phase,  or  when  stan- 
dards bodies  act  to  modify  or  add  provisions  of  model  codes  and  standards. 

The  diversity  and  changeability  of  design  criteria  have  tended  to  shorten  the 
useful  life  of  certain  important  software  tools,  most  notably  engineering  design 
programs.  The  checking  of  interim  solutions  against  constraints  and  design 
criteria  is  a necessary  component  of  the  engineering  design  process.  As  indi- 
cated earlier  in  this  report,  applicable  constraints  and  criteria  are  subject 
to  considerable  variation.  Engineering  design  software  in  current  use  incor- 
porates criterion  values  and  checking  algorithms  as  "hard  code."  As  a result, 
changes  brought  about  by  regulatory,  consensus,  and  other  processes  may  render 
software  obsolete  (at  least  temporarily)  and  require  costly  maintenance  [53]. 

A. 2 THE  STRUCTURAL  DESIGN  PROCESS 


Structural  analysis  concerns  the  determination  and  resolution  of  the  effects  of 
forces  acting  upon  and  within  a structure.  Such  force  effects  include  those 
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arising  from  within  the  structure  itself  (dead  and  live  loads)  , as  well  as 
those  external  to  the  structure  (e.g.,  wind  and  seismic  loads).  Structural 
design  is  a process  of  configuring  physical  elements  to  resist  forces  and 
loadings  in  relation  to  known  boundary  conditions  and  materials  properties, 
while  satisfying  desired  functional  requirements  and  specifications.  Products 
of  structural  analysis  include  reactions,  shears,  and  moments  for  beams, 
columns  and  other  members.  These  data,  when  employed  in  conjunction  with 
constraints,  design  criteria  and  material  characteristics,  enable  members  to 
be  proportioned  and  configured.  In  traditional  engineering  practice  (and  in 
the  commercially  available  CASD  systems)  structural  steel  member  selection, 
for  example,  is  accomplished  by  "looking-up"  the  desired  properties  in  pre- 
coded  standards  tables,  and  then  accepting  the  lightest  member  providing  these 
properties . 

Final  design  always  results  from  some  sequence  of  problem-solving  operations 
coupled  with  various  optimizations  [41].  Refer  to  figures  A. 2 and  A. 3.  The 
design  objective  usually  is  to  maximize  structural  serviceability  and  safety 
while  minimizing  design,  construction,  and  maintenance  costs.  This  is  accom- 
plished through  the  simultaneous  consideration  of  building  configuration,  load- 
ings, materials,  and  code  requirements.  Structural  optimization  has  been 
defined  as  designing  and  constructing  a structure  at  lowest  cost,  while  fulfill- 
ing well  defined  constraints  [44].  All  research  and  practice  in  structural 
engineering  is  directed  toward  this  goal;  structural  optimization  particularly 
connotes  the  development  and  application  of  automated  techniques  for  improving 
designs.  Thus,  the  computer  becomes  an  essential  tool  for  searching  and  sort- 
ing through  design  concepts,  and  for  proportioning  and  detailing  individual 
structural  elements. 

A. 3 THE  ROLE  OF  STANDARDS  IN  THE  BUILDING  DESIGN  PROCESS 


Standards  are  primary  mechanisms  for  communicating  technical  information  in  the 
construction  community.  For  purposes  of  this  discussion  the  term  "standard" 
includes  all  types  of  formal  documents  used  to  define  the  qualities  of  build- 
ings, building  products,  or  construction  processes.  During  the  design  process, 
standards  primarily  serve  to  ensure  provision  of  minimum  acceptable  levels  of 
public  health,  safety,  and  welfare.  The  domain  of  structural  engineering 
standards  includes  provisions  specifying  allowable  and  ultimate  design  stresses, 
and  stipulating  methods  to  be  employed  in  the  sizing,  configuration,  and 
connection  of  structural  members. 

A standard  is  usually  developed  by  a small  group  of  experts  who,  upon  completing 
a draft  standard,  submit  the  document  to  the  organization  responsible  for  its 
promulgation  and  maintenance.  However,  the  processes  of  promulgating  and  main- 
taining a standard  may  be  of  long  duration,  perhaps  on  the  order  of  three  to 
four  years  or  longer  between  versions.  In  addition,  rapidly  changing  societal 
demands  (such  as  those  concerning  life  safety  or  energy  conservation),  and  the 
emergence  of  new  technologies  (such  as  electronic  computation  and  new  materials) 
frequently  result  in  the  need  for  new  standards  and  changes  in  existing  stan- 
dards. While  such  factors  contribute  to  the  high  cost  of  maintaining  standards, 
they  also  increase  the  complexity,  and  therefore  the  cost,  of  maintaining  CASD 
software  systems.  This  is  because  checking  design  properties  against  standards 
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Collect  and  classify  data;  define 
the  problem;  develop  criteria  for 
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SYNTHESIS 
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Select  and  develop  the  optimal 
solution. 

Figure  A. 2 Fundamental  elements  of  the  design  process 
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Figure  A. 3.  Iterative  engineering  design  process 


is  a fundamental  feature  of  the  design  process  (and  therefore  a necessary 
element  of  CASD  software  systems),  and  because  much  of  the  effort  in  maintaining 
CASD  software  involves  keeping  pace  with  and  implementing  periodic  revisions  to 
standards. 
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APPENDIX  B.  GENERAL  TECHNICAL  CONSIDERATIONS  IN  THE  IMPLEMENTATION  OF  SOFTWARE 
FOR  COMPUTER-AIDED  STRUCTURAL  DESIGN 

Structural  design  is  a complex  task  involving  many  procedures  which  are  based 
on  scientific  principles,  professional  experience,  judgment  and  intuition. 

When  designing  a structure,  the  engineer  must  adequately  define  the  problem  at 
hand,  specify  the  criteria  by  which  candidate  solutions  will  be  judged,  synthe- 
size and  evaluate  candidate  designs,  and  ultimately  decide  upon  a single 
acceptable  solution.  Some  of  these  steps  are  more  well-defined  than  others. 

For  example,  while  the  engineer  may  rely  upon  intuition  or  past  experience  to 
a considerable  degree  when  selecting  a conceptual  approach  or  specifying  over- 
all design  criteria,  selecting  individual  structural  components  and  detailing 
individual  connections  are  likely  to  be  governed  by  scientifically  and 
empirically  supported  engineering  standards. 

Humans  can  solve  complex  engineering  problems  because  they  are  intelligent ; 
that  is,  humans  can  logically  derive  specific  instances  from  general  concepts, 
employ  relatively  efficient  strategies  for  searching  large  solution  spaces, 
and  improve  their  own  task  performance  by  learning  from  past  experiences.  These 
abilities  seem  particularly  necessary  during  the  least  well-defined  portions  of 
the  design  task,  but  may  be  relatively  unnecessarily  in  carrying  out  such  acti- 
vities as  calculating  stresses  and  selecting  structural  members  from  codified 
tables.  Currently  available  CASD  software  generally  is  not  artifically  intelli- 
gent^,  and  as  a result  these  systems  focus  only  on  aspects  of  design  which  lend 
themselves  to  determinate  mathematical  formulation.  In  general,  these  aspects 
have  been  limited  to  analyzing  candidate  structures  (i.e.,  resolving  forces 
acting  on  a structure  under  specified  loading  conditions)  and  selecting  and 
configuring  predefined  structural  members  and  components  (i.e.,  identifying 
components  which  most  efficiently  satisfy  all  applicable  constraints  upon  the 
structure,  on  the  basis  of  generally  accepted  engineering  standards).  Thus, 

CASD  software  presently  in  commercial  use  is  intended  to  assist  the  engineer 
by  automating  only  those  aspects  of  design  which  are  least  open  to  subjective 
interpretation. 

The  remainder  of  the  present  discussion  considers  a number  of  problems 
associated  with  available  CASD  systems.  Of  particular  interest  are  difficulties 
in  applying  codified  engineering  standards  during  automated  structural  design. 
Technical  considerations  in  CASD  first  are  discussed,  and  several  established 
computer-based  systems  then  are  reviewed. 

B.l  TECHNICAL  CONSIDERATIONS 

The  performance  of  CASD  software  systems  may  be  specified  and  evaluated  in 
relation  to  four  issues.  These  include:  (1)  the  efficiency  of  engineering 

data  management,  (2)  the  effectiveness  of  structural  analysis,  proportioning, 
and  optimization  procedures,  (3)  the  efficiency  of  procedures  for  constraint 
processing,  and  (4)  the  ease  with  which  the  user  interacts  with  the  automated 
design  system. 


1/  An  exception  is  SACON,  a structural  analysis  "consulting  system"  [6]. 
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B.1.1  Data  Structures  and  Database  Management 

Overview.  There  are  two  general  approaches  to  maintaining  data  generated  or 
used  by  structural  analysis  and  design  software.  These  are  application-specific 
files , and  centralized  application-independent  databases.  Application-specific 
data  files  are  specially  written  (either  manually  or  by  an  application  program) 
to  be  read  by  either  a single  application  program,  or  by  a small  group  of  highly 
interrelated  programs  which,  taken  together,  comprise  a unique  application. 

The  main  advantages  of  application-specific  files  include  their  low  development 
cost  and  their  ability  to  insure  high  levels  of  data  security  and  integrity. 
Essential  disadvantages  of  the  application-specific  approach  are  the  facts  that 
data  produced  by  one  application  may  not  be  readily  available  to  other  applica- 
tions (and  as  a result,  there  may  exist  considerable — and  costly — redundancy  in 
data  used  by  similar  applications),  and  data  stored  in  application-specific 
files  may  be  difficult  and  costly  to  maintain  [53]. 

Centralized  application- independent  databases,  in  contrast,  maintain  data  in  a 
form  making  them  acceptable  to  the  widest  practical  range  of  application  pro- 
grams. Advantages  of  centralized  databases  include  the  facts  that  they  sub- 
stantially reduce  data  redundancy  (since  data  required  by  many  application 
programs  need  be  stored  only  once) , they  provide  special  facilities  for 
accessing  and  maintaining  data  (the  so-called  "database  management  system,”  or 
DBMS) , and  they  enforce  standards  for  representing  information  within  indi- 
vidual applications.  However,  DBMS  are  usually  difficult  and  costly  to  create, 
requirements  for  data  security  and  integrity  may  be  difficult  to  satisfy,  the 
form  of  data  most  appropriate  to  the  widest  range  of  applications  may  be 
difficult  to  determine,  and  access  time  to  data  may  restrict  computational 
efficiency. 

In  most  complex  application  areas,  including  structural  engineering,  it  has 
already  become  quite  clear  in  practice  that  the  benefits  of  application- 
independent  databases  far  outweigh  those  of  application-specific  files  [53]. 

Some  years  ago,  a number  of  architectural/engineering  firms  in  the  United 
States,  desiring  to  automate  certain  analytical  and  design  functions,  began 
this  process  by  procuring  various  independently-developed  software  packages  and 
hardware  systems.  Many  of  these  programs  are  still  in  use  today,  and  they  pri- 
marily deal  with  energy  analysis,  structural  analysis,  and  automated  drafting. 
The  output  from  such  packages  typically  are  stand-alone  reports  and  drawings. 

The  operation  of  each  program  requires  a unique  data  input  protocol.  Early 
users  of  such  software  quickly  found,  however,  that  much  of  the  input  data 
required  for  each  program  is  both  redundant  across  the  programs,  and  is  incom- 
patible with  those  programs  for  which  they  were  not  specifically  intended.  For 
example,  while  each  analysis  or  drafting  program  reads  geometric  descriptors 
into  the  computer,  few  programs  read  these  data  in  the  same  form.  Moreover, 
users  noted  that  output  from  one  program  could  usefully  serve  as  input  to 
another.  Thus,  certain  data  produced  during  structural  design  might  appear  in 
a final  drawing,  schedule,  or  specification.  But  to  accomplish  this,  a single 
geometric  description  must  be  reformated  to  "fit"  each  application  program, 
and  in  addition,  data  generated  automatically  by  one  program  often  must  be 
reformatted  manually  before  they  can  be  used  by  another  program. 
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Initial  attempts  to  solve  these  problems  within  the  production-oriented 
environment  of  architectural/engineering  practice  involved  writing  data  manipu- 
lation "pre-"  and  "post-processors,”  and  placing  these  between  the  production 
programs.  The  processors  are  special  programs  that  rewrite  data  files  making 
project  data  compatible  across  relevant  application  programs,  and  also  less 
redundant.  More  recently,  a number  of  integrated  building  design  systems  have 
been  developed  which  maintain  a single,  readily  accessible,  project-wide  data- 
base. Examples  of  such  systems  include  ICES,  POLO,  and  GENESYS  for  structural 
engineering  data,  BDS  for  architectural  design  data,  and  CAEADS  and  IPAD  for 
both  design  and  project  management  data.  In  general,  the  goal  in  configuring 
such  data  systems  is  to  support  the  design  of  complex  structures  from  early 
specification  to  full  design  development  and  construction  instructions  [18]. 
With  the  exception  of  IPAD  and  CAEADS,  however,  systems  currently  available 
focus  on  only  a portion  of  the  design/development  process.  Database  management 
aspects  of  integrated  design  systems  are  reviewed  in  considerable  detail  by 
Mitchell  and  Oliverson  [49],  Rehak  and  Lopez  [53],  and  Eastman  [15,  16]. 

As  noted  earlier,  DBMS  to  support  CAD  tasks  and  applications  may  be  both 
complex  and  costly  to  develop.  In  general,  engineering-oriented  DBMS  may  be 
based  upon  hierarchical,  network,  or  relational  data  models.  A succinct  sum- 
mary of  these  models,  and  a consideration  of  their  ramifications  for  CASD,  have 
been  provided  by  Rehak  and  Lopez  [53].  Some  investigators  have  suggested  that 
existing  commercially  available  DBMS  are  quite  capable  of  supporting  facility 
design  databases  (e.g.,  Armatage  and  Hall  [4]  in  connection  with  computer-aided 
space  planning  and  facility  layout).  Others  have  argued  that  more  specialized 
DBMS  are  likely  to  be  required  because  of  the  volume  of  data  involved  and  the 
nature  of  the  design  process  (e.g.,  Rehak  and  Lopez  [53]  concerning  structural 
design,  and  Eastman  [15,  16]  concerning  integrated  CAD). 

Representing  project-specific  information.  Project-specific  inf ormation 
generally  includes  design  constraints,  attributes  of  building  subsystems  and 
components,  and  representations  of  geometric  configuration.  Design  constraints 
involve  functional  requirements  (minimum  clearances,  dimensional  constraints, 
spatial  requirements,  etc.),  requirements  imposed  by  codes  and  standards,  and 
limitations  concerning  site  usage,  costs,  and  such  factors  as  access  to  solar 
energy.  The  representation  of  functional  requirements  and  spatial  topology  has 
been  considered  by  Mitchell  [48],  Mitchell  and  Oliverson  [49],  Liggett  and 
Mitchell  [45,  46],  and  by  Eastman  [17].  Automated  engineering  design  poses 
somewhat  different  problems  in  the  representation  of  design  constraints,  pri- 
marily because  engineering  decisions  require  precise  dimensional  descriptions 
of  discrete  building  components.  In  structural  engineering,  constraints  are 
defined  as  project-specific  applications  of  criteria  imposed  by  building  codes 
and  standards  [66].  To  evaluate  constraints  on  a structural  system,  it  is 
necessary  to  apply  applicable  criteria  at  appropriate  points  in  space  corre- 
sponding to  joints  or  other  locations  along  structural  members.  The  systematic 
checking  of  design  instances  against  generic  criteria  is  termed  constraint 
processing.  This  task  requires  that  project  geometric  data  be  maintained  with 
sufficient  precision  to  permit  valid  design  decisions.  Moreover,  because  com- 
plex engineered  structures  may  require  literally  thousands  of  constraints  to 
be  evaluated,  constraint  processing  also  requires  that  project  data  be  rapidly 
and  efficiently  retrievable.  Problems  associated  with  designing  algorithms 
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and  data  structures  for  constraint  processing  in  structural  design  have  been 
considered  by  Wright  et  al.,  [66],  Holtz  and  Fenves  [38]  and  Rehak  and  Lopez 
[53]. 

Attributes  of  building  subsystems  and  components  include  descriptions  of 
subsystem  and  component  types,  materials,  unit  dimensions  and  weights,  perfor- 
mance data,  relationships  among  components  of  individual  subsystems  (e.g., 
duct8-to-furnace) , and  relationships  among  subsystems  to  a building  (e.g., 
HVAC-to-structural) . According  to  Hayward  [36],  a complete  building  descrip- 
tion may  best  be  represented  by  data  contained  in  two  separate  files,  one 
holding  descriptions  of  components,  the  other  holding  information  about  spa- 
tial occurrences  of  these  components.  Since  a particular  component  is  likely 
to  occur  many  times  in  a given  building,  this  separation  permits  considerable 
economy  in  data  storage.  The  representation  of  such  project  information  has 
been  accommodated  in  the  development  of  such  integrated  design  DBMS  as  OXSYS/ 
BDS  [11,  54,  55],  IPAD  [2],  and  also  is  evident  in  the  work  Borkin  et  al.,  [7] 
on  geometric  modeling. 

Because  buildings  are  artifacts  with  specific  shapes  and  finite  boundaries, 
geometric  modeling  and  representation  is  fundamental  to  the  objectives  of  CASD. 
Specification  of  structural  form  requires  definition  of  spatial  enclosure 
(i.e.,  topological  relationships  among  components),  location  of  components  and 
subsystems  in  three-dimensional  space,  and  description  of  shapes  and  boundary 
conditions.  Geometric  modeling  and  representation  applicable  to  CASD  also 
have  been  treated  [5,  7,  39,  49,  52,  56,  65]. 

Representing  codes  and  standards.  In  contrast  to  project-specific  data  which 
describe  aspects  of  a finite  physical  entity,  the  contents  of  building  codes, 
standards,  and  specifications  are  generic  data  applicable  across  all  projects 
in  any  given  class.  Constraint  processing  merges  design  data  and  standards 
data  to  create,  conduct,  and  record  the  results  of  tests  of  specific  loading 
and  resistance  conditions  at  given  spatial  locations.  To  accomplish  this,  it 
is  necessary  that  both  design  data  and  standards  share  a logical  structure 
[66].  Thus,  descriptors  for  discrete  structural  elements  in  a given  project 
may  be  subscripted  to  denote  member  identifications,  segment  lengths,  shape 
categories,  and  the  like.  Similarly,  standards  data  may  be  subscripted  to 
enable  active  standards  data  to  be  identified,  to  connect  active  provisions 
with  associated  design  data,  and  to  establish  precedence  (i.e.,  dependence  and 
ingredience)  relationships  among  provisions  of  a standard.  The  purpose  of  a 
shared  logical  structure,  then,  is  to  assure  that  correct  and  complete  data 
are  available  for  any  given  criterion  check,  and  that  checks  are  conducted  in 
the  proper  sequence. 

Efficient  constraint  processing  requires  explicit  relations  between  elements  of 
standards  data  (i.e.,  individual  provisions).  This  objective  is  most  readily 
achieved  when  the  provisions  of  a standard  have  been  modeled  as  decision 
tables,  and  the  relations  among  provisions  have  been  structured  as  networks. 
Such  formulations  of  standards  are  feasible  and  have  been  demonstrated,  and 
with  the  availability  of  SASE  appropriate  organizations  and  formats  for  CAD 
standards  databases  are  now  within  the  reach  of  researchers. 
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B.1.2  Constraint  Processing 

The  constraint  processing  algorithm  discussed  by  Wright  et  al.,  [66]  specifies 
a procedure  independent  of  both  generic  standards  data  (design  criteria)  and 
project-specific  design  data.  Ideally,  therefore,  software  implementations  of 
the  constraint  processing  algorithm  should  permit  standards  to  be  referenced  as 
external  data,  as  are  project  data.  In  this  way,  software  maintenance  to 
ensure  the  validity  of  standards  employed  during  criterion  checking  can  be 
reduced  to  the  seemingly  trivial  task  of  exchanging  one  standards  database  for 
another  (the  author  recognizes  that  the  complementary  task  of  generating  such 
external  standards  databases  in  the  useable  format  is  by  no  means  trivial;  see 
Harris  and  Wright,  [35]).  However,  current  implementations  of  constraint 
processing  in  available  CASD  software  systems  do  not  possess  such  general 
purpose  capabilities. 

‘In  the  procedure  initially  envisioned  by  Wright  et  al.,  [66]  a constraint  is 
defined  as  a particular  application  of  a design  criterion  imposed  by  a standard 
or  user  requirement.  Within  the  domain  of  structural  engineering,  a constraint 
typically  is  characterized  by  the  mode  of  failure  specified  in  the  criterion 
(e.g.,  vertical  shear) , the  point  of  application  of  the  criterion  (e.g.,  beam 
endpoint),  the  physical  location  of  the  point  of  application,  and  the  loading 
or  environmental  condition  producing  the  responses  referenced  in  the  criterion. 
The  function  of  the  constraint  processing  procedure,  then,  is  to  evaluate  all 
critical  points  in  a structure  and  determine  whether,  under  the  given  loading 
conditions,  applicable  constraints  are:  (1)  "active",  that  is,  the  element  as 

designed  provides  required  resistance  within  allowable  tolerances,  (2)  "vio- 
lated" , that  is , the  element  as  designed  provides  resistance  below  the  minimum 
permitted,  or  (3)  "inactive”,  that  is,  the  element  as  designed  provides 
resistance  in  excess  of  that  required.  Note  figure  B.l. 

In  the  formulation  by  Wright  et  al.,  two  basic  operations  recur  in  constraint 
processing.  These  are  SEEKing  a value  for  an  absent  attribute  (e.g.,  area, 
moment,  deflection)  and  WARNing  that  the  current  value  of  an  attribute  has  been 
changed.  After  an  iteration  of  the  design  cycle  has  been  completed,  the  SEEK 
function  searches  all  ingredient  attributes  defining  a specific  design  condi- 
tion and  identifies  those  voided  (or  otherwise  absent)  during  the  cycle  and 
requiring  (re) computation.  SEEKing  is  performed  by  tracing  design  parameters 
backward  through  a constraint’s  ingredients,  until  a basic  input  value  is 
provided.  For  example,  modification  of  a beam  during  one  design  cycle  may  void 
the  area  of  a column  determined  earlier.  This  area  must  be  flagged  for  recom- 
putation, the  ingredients  of  the  area  computation  (width  and  depth)  must  be 
identified,  and  the  values  for  these  variables  must  be  provided.  Similarly, 
the  complementary  WARN  function  keeps  track  of  changes  in  design  parameters  and 
attributes,  and  voids  other  dependent  attributes  of  a specific  design  condition 
for  which  an  antecedent  parameter  has  been  changed.  WARNing  is  accomplished 
by  tracing  design  parameters  forward  through  a constraint's  dependents,  until  a 
logical  termination  point  is  reached.  Taken  together,  SEEK  and  WARN  provide 
the  link  between  the  design  database,  the  standards  database,  and  the  rules 
for  checking  design  conformance. 
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The  status  values  of  constraints  themselves  are  data  which  describe  important 
characteristics  of  a candidate  design  solution.  These  data  indicate  precisely 
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CONSTRAINT  STATUS 


INACTIVE 


ACTIVE 


VIOLATED 


RESISTANCE  Z(A/R) 


where  e„  and  eT  denote  tolerances 
H L 


(from  Wright  et  al.  [66]) 


Figure  B.l.  General  fora  for  design  criterion 
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the  points  at  which  the  design  is  sufficient  (denoted  by  active  constraints), 
insufficient  (violated  constraints),  and  "overdesigned"  (inactive  constraints). 
Thus,  they  indicate  to  the  designer  (whether  a human  engineer  or  an  automated 
structural  design  system)  objectives  for  design  optimization. 

Commercially  available  CASD  software  systems  such  as  ICES/STRUDL  and  GENESYS 
implement  variants  of  such  a procedure.  Accordingly,  these  systems  automati- 
cally design  or  select  structural  members  on  the  basis  of  minimum  weight  or 
other  objectives  specified  by  the  user.  They  do  not,  however,  physically  sepa- 
rate criteria  and  the  checking  algorithm  from  analysis  and  other  CASD 
components,  a key  goal  for  enhancing  the  effectiveness  of  CASD  technology  [21, 
53,  66]. 

B.1.3  Structural  Analysis,  Design,  and  Optimization 

•In  general,  automated  design  procedures  arrive  at  a design  the  engineer  could 
equally  as  well  have  obtained  if  time  and  money  were  available  to  directly 
search  among  the  design  alternatives  [44].  Thus,  CASD  software  systems  are 
typically  configured  to  design  assemblages  by  first  performing  a structural 
analysis  to  obtain  force  effects  in  the  elements,  and  then  by  optimizing  each 
element  separately.  The  resulting  structure  is  then  reanalyzed,  and  the  proce- 
dure repeated.  In  most  cases,  this  process  converges  rapidly  to  an  acceptable 
solution. 

Goble  and  Moses  [30]  point  out,  however,  that  element  design  procedures  are 
limited  to  constraints  which  describe  only  element  behavior,  and  therefore  to 
structures  where  design  is  based  strictly  on  fixed  codes  and  procedures. 
Accordingly,  optimization  based  on  element  design  may  be  relatively  ineffective 
where  overall  system  constraints  such  as  stability,  natural  frequency,  aero- 
elastic  behavior,  and  overall  deflection  must  be  considered.  Moreover,  the 
element  design  procedure  is  not  applicable  when  additional  variables  relating 
to  the  whole  structure,  such  as  geometry,  interelement  sensitivity  to  stiff- 
ness, material,  fabrication,  and  construction,  are  introduced.  In  these 
special  cases,  element  optimization  is  useful  only  as  a subroutine  within  a 
broader  and  far  more  complex  set  of  mathematical  operations.  One  final  diffi- 
culty noted  with  element  optimization  based  CASD  concerns  the  possibility  that 
designing  one  element  at  a time  might  lead  to  large  number  of  members  of  dif- 
ferent size  being  specified  in  a single  structure.  Solutions  to  this  problem 
have  been  developed  using  dynamic  programming  routines  which  consider  the 
results  of  element  optimization,  and  then  optimally  select  elements,  and  the 
number  of  each,  to  be  used  [30,  50].  Similar  solutions  are  implemented  in  the 
commercially  available  CASD  packages. 

B.1.4  Human  Factors  Considerations  in  CASD 

Technical  conserations  in  the  user-machine  interface  also  are  important  to  an 
effective  standards  interface.  Human  interactions  with  software  systems  and 
computer-based  engineering  design  tools  typically  concern  (1)  data  entry, 

(2)  display  (screen)  layout  and  design,  and  (3)  task  sequence  control.  Experi- 
ence and  research  in  human  factors  engineering  suggests  that  optimal  system 
performance  can  best  be  assured  when  the  needs  of  system  users  have  been 
effectively  accommodated  [59]. 
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Human  factors  considerations  play  a significant  role  in  SI/CAD.  In  particular, 
it  is  important  that  the  analyst  be  kept  informed  about  the  status  of  con- 
straints as  these  are  evaluated.  Only  with  this  information  can  the  designer 
effectively  Intervene  in  the  design  process.  Similarly,  the  engineering 
designer  should  be  kept  informed  about  the  standard  and  version  in  effect  for  a 
given  procedure,  and  should  be  provided  continuous  feedback  regarding  provisions 
being  invoked  at  any  point.  These  are  especially  important  where  processing  is 
distributed  among  or  being  monitored  by  a number  of  participants.  Such  feedback 
permits  analysts  to  study  the  constraint  evaluation  "trail",  the  basis  for  auto- 
matic design  decisions  and  for  intelligent  user  intervention  in  the  design 
process.  Clearly,  It  is  up  the  the  system  software  designer  to  provide  such 
enhancements  and  capabilities  in  CASD  systems. 

While  experts  have  not  as  yet  adopted  specific  performance  requirements  for 
"software  design,  they  generally  agree  that  "good"  software  systems  are  easy  to 
learn,  produce  simple  and  readable  displays,  are  supported  by  easy-to-follow 
documentation,  and  are  written  for  less  specialized  users  (not  for  computer 
experts).  To  develop  software  that  may  be  correctly  and  efficiently  used, 
human  factors  specialists  consider  a number  of  basic  principles  [59]:  (1)  The 

software  should  provide  the  user  with  feedback  that  is  immediate  and  unambig- 
uous. Feedback  should  be  provided  at  the  location,  and  in  the  form,  expected 
by  the  user.  The  completion  of  some  process,  the  failure  of  a process  to 
successfully  terminate,  incorrect  input  syntax,  and  data  entry  errors  are 
examples  of  points  requiring  feedback  to  the  user.  Such  information  should  be 
sufficiently  explicit  to  advise  the  user  about  what  to  do  next.  (2)  Program 
organization  and  program-user  dialog  should  be  consistent.  The  system  designer 
should  establish  and  strictly  follow  rules  which  permit  the  user  to  learn  a 
part  of  the  system,  and  then  to  apply  this  new  knowledge  to  other  parts  of  the 
system.  That  is,  one  part  of  the  system  should  not  contradict  any  other  part. 
(3)  Use  of  the  program  should  be  matched  to  operators*  skill  levels  and  roles. 

From  a human  factors  viewpoint,  software  systems  for  structural  engineering 
pose  new  problems  for  the  programmer.  These  problems  derive  largely  from  the 
complexity  and  data  intensity  of  most  structural  engineering  problems,  the 
predisposition  of  structural  designers  to  think  in  visual  terms,  and  the  inter- 
relationship between  principal  engineering  tasks,  particularly  analysis,  propor- 
tioning, and  optimization.  To  reduce  the  impact  of  these  sources  of  complexity, 
a number  of  different  modes  for  controlling  complex  processing  in  CASD  have 
been  employed  in  practice.  Each  has  different  human  factors  implications.  For 
example,  the  ICES  and  POLO  program  development  environments  rely  on  the  use  of 
POLs  to  simplify  data  entry  and  sequence  process  control,  and  thereby  reduce 
the  likelihood  of  user  error.  POLs  are  intended  to  simplify  system  use  by 
reducing  person-to-computer  communications  to  an  abbreviated  English-like  for- 
mat. Consider  the  statement  "JOINT  COORDINATES"  in  ICES/STRUDL,  which  tells 
the  computer  that  the  following  data  specify  spatial  locations  of  member  end- 
points, or  "STIFFNESS  ANALYSIS,"  another  STRUDL  command,  which  requests  a 
particular  process  to  be  initiated. 

POLs  have  been  augmented  to  better  suit  graphically  oriented  users  such  as 
design  engineers.  For  example,  graphic  input  mode  permits  the  designer 
literally  to  draw  a frame,  solid,  or  mesh  directly  onto  the  screen,  while  the 
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computer  automatically  records  the  two-  or  three-dimensional  coordinates  of 
member  (or  element)  endpoints.  Similarly,  "menus"  of  all  available  modes  and 
commands  can  be  continuously  displayed  on  the  screen,  and  the  user  can  auto- 
matically be  prompted  to  select  a command  from  the  menu  at  appropriate  occa- 
sions during  a design  session.  In  addition,  menus  do  not  require  the  user  to 
memorize  lengthy  lists  of  commands  and  mnemonics  (or  to  frequently  consult  the 
user's  manual). 

Human  factors  considerations  also  have  resulted  in  the  better  utilization  of 
graphics  in  CASD  output  displays.  Most  significant  is  the  application  of 
interactive  graphics  in  CASD,  in  which  graphic  output  from  one  design  cycle  may 
be  interpreted  and  manipulated  by  the  user,  and  then  dispatched  for  processing 
as  input  to  the  next  cycle.  Among  the  most  innovative  applications  of  inter- 
active graphics  has  been  in  the  area  of  structural  mechanics,  in  which  it  is 
rtow  possible  to  simulate  and  visualize  in  three  dimensions  load  displacements, 
deformations,  and  failure  modes  [1]. 

B.2  INTEGRATED  COMPUTER-AIDED  STRUCTURAL  DESIGN  SYSTEMS 


B.2.1  State-of-the-Art 

Potential  economies  derivable  through  the  integration  and  distribution  of  CASD 
tasks  were  discussed  in  appendix  section  A. 1 of  this  report.  In  particular, 
cost  savings  resulting  from  minimizing  redundancy  and  error  in  a project  data- 
base were  considered.  However,  it  also  was  noted  that  many  of  the  goals  asso- 
ciated with  ICAD  and  DICAD  may  be  somewhat  difficult  and  costly  to  obtain.  At 
present,  impediments  to  ICAD  include:  (1)  lack  of  a uniform  approach  to 

developing  integrated  engineering  design  software;  (2)  lack  of  consensus 
regarding  the  best  model  for  a task-independent  database  for  building  design; 
and  (3)  lack  of  accepted  data  definition  and  data  manipulation  language  stan- 
dards applicable  to  building  industry  participants.  An  additional  technical 
impediment  to  the  implementation  of  effective  DICAD  concerns  the  lack  of  stan- 
dards for  interfacing  hardware  and  operating  systems  of  diverse  design  and 
manufacture,  although  this  is  not  the  focus  of  the  present  report. 

Rehak  and  Lopez  [53]  have  argued  that  the  development  of  integrated 
computer-based  engineering  aids  has  been  hampered  further  by  the  proliferation 
of  singlepurpose  software  tools.  According  to  these  investigators,  single- 
purpose software  tends  to  work  reasonably  well  in  practice,  under  the  very 
limited  sets  of  conditions  for  which  it  was  designed.  But  because  each  indi- 
vidual program  usually  is  based  on  a unique  view  of  a limited  problem  domain, 
and  because  engineering  practitioners  themselves  are  limited  in  their  technical 
concerns  and  responsibilities  in  connection  with  a building  project,  potential 
economies  deriving  from  a more  sophisticated  engineering  software  concept  have 
not  proved  obvious  in  practice.  It  may  be  that  future  widespread  development 
of  ICAD  and  DICAD,  and  the  economies  derivable  through  their  implementation, 
must  follow  certain  fundamental  changes  in  the  building  process  itself.  This 
concept  is  supported  by  the  previously  cited  pioneering  of  in-house  ICAD  by 
architectural/engineering  firms  already  organized  to  integrate  essential 
building  development  tasks.  Recent  experiences  with  ICAD,  and  to  a lesser 
degree  DICAD,  cluster  into  three  broad  categories:  (1)  industry-wide  systems 
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for  computer-aided  design,  design  management,  and  manufacture,  represented  by 
IPAD;  (2)  environments  for  CAD  system  development,  represented  by  ICES  and  POLO 
and  (3)  systems  for  linking  disparate  CAD  software  components,  represented  by 
GENESYS  and  CAEADS.  General  aspects  of  these  approaches  applicable  to  research 
on  SI/CAD  now  can  be  reviewed. 

IPAD  is  perhaps  the  most  ambitious  undertaking  to  develop  an  integrated  and 
distributed  computer-based  engineering  environment.  IPAD  was  developed  by  the 
Boeing  Computer  Services  Company  for  the  National  Aeronautics  and  Space  Adminis 
tration.  The  system  consists  of  computer  programs  intended  to  support  the 
aerospace-vehicle  design  process  by  aiding  design  management  tasks,  technical 
tasks,  and  supporting  requirements.  All  project  management  and  technical  data, 
together  with  standards  data,  are  stored  in  a single  task-independent  database. 
IPAD  functions  permit  project  personnel  to  query  the  database  and  perform  oper- 
ations on  project  data.  IPAD  sequences  the  task  elements  of  a complex  opera- 
tion, providing  common  access  to  a single  database  by  the  various  participants 
in  the  design/development  process.  Such  capabilities  can  be  provided  either  on 
a single  host  computer,  or  across  heterogenous  machines  on  a distributed  basis 
[13]. 

Under  IPAD,  engineering  analysis  and  design  are  treated  either  by  IPAD-supplied 
functions  and  programs,  or  by  user-defined  software  components.  When  develop- 
ing special-purpose  software,  the  user  must  also  develop  and  implement  the 
necessary  interfaces  between  the  application  program,  the  IPAD  data  manager, 
and  the  IPAD  operating  system.  Each  added  application  program  must,  moreover, 
contain  its  own  user  interface. 

While  IPAD  provides  computer-based  support  for  long-term  multi-user  design/ 
development  process  management , in  contrast  ICES  and  POLO  provide  environments 
for  engineering  software  development . These  systems  provide  data  management 
and  interface  facilities;  linking  new  application  programs  is  accomplished 
through  the  database  and  support  system  software.  An  approach  combining  both 
a program  development  environment,  and  a cadre  of  built-in  applications,  all 
linked  through  an  application-specific  executive  system  is  illustrated  by 
GENESYS. 

In  contrast  with  IPAD,  ICES,  and  POLO,  the  United  States  Army  Corps  of 
Engineers'  CAEADS  consists  primarily  of  a collection  of  single-purpose  (albeit 
interconnected)  programs  to  assist  "pre-concept"  building  design.  These 
include  SKETCH  (floor  plan  creation  and  editing),  SEARCH  (design  evaluation), 
BLAST  (energy  analysis),  and  similar  functions.  CAEADS  (and  GENESYS,  which 
also  links  individually  developed  software  components)  illustrates  certain 
problems  which  may  arise  when  system  integration  is  sought  by  linking  inde- 
pendently developed  computer  programs.  An  example  problem  in  CAEADS  concerns 
invoking  the  BLAST  energy  analysis  option.  Current  data  describing  the  project 
must  first  be  passed  to  an  intermediate  processor  which  develops  a BLAST  data 
file  and  run-stream.  This  new  off-line  run-stream  is  then  submitted  as  a 
batch  job  on  a separate  computer.  Results  of  the  analysis  are  provided  in  a 
report,  and  do  not  automatically  update  the  CAEADS  project  database  (in 
contrast  with  SEARCH,  which  does  update  the  database).  Thus,  database 
maintenance  on  the  basis  of  BLAST  results  is  a manual  task.  CAEADS  has  no 
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structural  analysis  and  design  capability  at  present,  and  therefore  will  not  be 
treated  further  in  the  present  report. 

B.2.2  Riture  Prospects  for  General  Purpose  Integrated  CASD 

Thus,  ICES,  POLO,  GENESYS,  and  to  a lesser  extent  CAEADS  may  be  viewed  as  ICAD 
support  systems  [53].  Each  provides  database  management,  language  translation, 
and  other  run-time  features,  and  was  primarily  designed  to  support  large  analy- 
sis applications  (e.g.,  STRUDL  under  ICES,  and  FINITE  under  POLO).  None  of 
these  support  systems  contains  application-independent  constraint-processing 
capabilities,  and  both  code-checking  algorithms  as  well  as  standards  data  must 
be  provided  within  individual  application  programs.  Under  each  of  these  sys- 
tems, therefore,  program  maintenance  to  assure  the  currency  of  applicable 
building  codes  and  standards  may  be  time-consuming  and  costly.  Similarly, 
users  of  these  systems  are  "locked  into"  applying  only  those  standards  that 
have  been  pre-programmed  into  the  design  software. 

If  ICES,  POLO,  and  GENESYS  exemplify  the  current  generation  of  CAD  system 
integration,  then  the  next  generation  of  such  systems  will  be  distinguished  by 
their  considerably  more  general  purpose  capabilities.  Ideally,  general  purpose 
ICAD  (GP/ICAD)  systems  will  be  functionally  independent  of  computing  hardware, 
application  discipline,  design  task,  and  standards  and  other  design  constraints. 

Thus,  they  will  ensure  that  diverse  discipline-specific  application  programs 
can  be  incorporated  at  any  point  during  the  development  of  a complex  building 
project,  and  that  project  knowledge  can  be  efficiently  and  correctly  shared 
among  the  numerous  applications.  Moreover,  future  GP/ICAD  systems  will  readily 
enable  simultaneous  design  processing  by  various  participants,  and  will  permit 
the  design  of  large  or  complex  structures  to  be  distributed  geographically 
(even  where  diverse  contributors  employ  different  computing  machinery,  data 
structures  and  data  definition  languages,  etc.). 

Rehak  and  Lopez  [53]  have  offered  a GP/ICAD  concept  design  intended  to  mitigate 
most  important  problems  associated  with  current  generation  integrated  engineer- 
ing design  systems.  The  remainder  of  this  section  describes  the  approach  taken 
by  these  investigators.  Designated  "Computer  Aided  Engineering  Software  Envi- 
ronment" (CAESE)  by  Rehak  and  Lopez,  the  system  is  intended  to  perform  neither 
as  a single  ICAD  device  nor  as  a collection  of  diverse  programs.  Rather,  it  is 
a collection  of  system  components  applicable  to  CASD  and  other  highly  complex 
engineering  problems.  CAESE  is  a prototypical  design  which  has  not  as  yet  been 
implemented  as  a working  software  system. 

CAESE  is  envisioned  to  consist  of  two  levels.  The  top  level  is  the  applications 
environment , in  which  reside  all  domain-specific  tools,  programs,  and  data 
required  to  perform  actual  design  and  engineering  computations  in  connection 
with  a given  project.  In  this  context,  the  term  "domain"  denotes  a particular 
project,  discipline,  field  of  knowledge,  or  area  of  engineering  practice.  The 
bottom  level  contains  the  system  environment,  in  which  reside  all  components, 
support  software,  and  data  which  are  both  domain-  and  application-independent. 
This  level  provides  engineering  design  and  computational  support,  but  itself 
performs  no  engineering  tasks.  Also  at  the  bottom  level  is  the  support 
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environment , which  provides  tools  for  developing  and  maintaining  both  the 
system  and  application  levels. 

The  system  environment  (bottom  level)  is  envisioned  to  consist  of  components 
required  to  provide  system  and  run-time  support  features  needed  to  solve  engi- 
neering design  problems.  Components  include  an  engineering-oriented  database 
management  system,  an  engineering  design  process  controller,  a constraint  pro- 
cessor (i.e.,  standards  interface),  a project  manager,  and  user-system  inter- 
faces. The  support  environment  (also  at  the  bottom  level)  assists  the  user  and 
system  programmer  in  developing,  managing,  and  maintaining  various  software 
components.  This  environment  includes  software  for  encoding  building  codes  and 
standards  into  machine-processible  form,  software  for  developing  and  machine- 
encoding  knowledge-based  rules  for  driving  the  design  process,  programming 
languages  for  developing  system  and  application  components,  and  other  similar 
support  features. 

All  engineering  analysis  and  design  is  envisioned  to  occur  within  the 
application  environment  of  CAESE  (the  top  level).  CAESE  is  intended  for  those 
applications  encompassing  large,  multi-discipline  problem  domains.  These  are 
typified  as  being  large-scale  projects  which  are  complete  systems  containing  a 
number  of  integrated  subsystems  from  various  engineering  disciplines,  which 
derive  from  relatively  ill-structured  problems,  and  which  are  governed  by  a 
variety  of  standards.  Examples  of  such  projects  include  nuclear  power  plants, 
off-shore  drilling  platforms,  high-rise  buildings,  aircraft,  and  even 
large-scale  software. 

Each  application  domain  is  viewed  as  an  individual  application  environment 
(e.g.,  CAESE -Nuclear  Power  Plants;  CAESE-Aircraft ; etc.).  Within  each  applica- 
tion environment,  various  subsystem  software  modules  and  databases  representing 
numerous  engineering  disciplines  are  integrated  to  form  a complete  engineering 
design  system.  Many  subsystems  and  modules  are  cross-disciplinary  in  their 
function,  and  need  only  be  stored  once  in  either  the  system  or  support  environ- 
ments. Examples  include  programs  for  finite  element  analysis,  proportioning, 
and  constraint  processing,  which  are  applicable  to  the  design  of  office  build- 
ings, off-shore  platforms,  ships,  and  so  on.  All  such  elements  are  then  linked 
to  create  a unique  application  environment  which  appears  unique  to  the  user. 

Rehak  and  Lopez's  conceptual  design  for  CAESE  represents  only  an  initial  step 
in  defining  the  next  generation  of  engineering  computer  aids.  CAESE  software 
development,  however,  is  expected  to  involve  numerous  tasks  and  require  hundreds 
of  person-years.  Once  system  and  support  environments  have  been  developed  and 
tested,  it  will  be  necessary  to  select  characteristic  applications  and  develop 
the  necessary  application  environment  software  and  interfaces.  Finally,  actual 
engineering  problems  for  which  there  are  known  solutions  must  be  redesigned 
under  CAESE,  so  that  the  validity  and  effectiveness  of  the  entire  system  may  be 
evaluated  [53]. 
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APPENDIX  C:  ELEMENTS  OF  COMPUTER-INTEGRATED  CONSTRUCTION 


C.l  A NATIONAL  PROBLEM 


The  efficiency  of  the  building  delivery  process  can  be  improved  through  reliance 
on  computers  in  many  of  the  individual  tasks  comprising  the  whole,  such  as 
design,  analysis,  drafting,  bid  preparations,  construction  planning,  and  regula- 
tory review.  Moreover,  the  efficiency  of  the  process  can  be  improved  through 
reliance  on  computers  for  communication  and  coordination  of  technical  data 
between  the  various  processes  that  comprise  building  delivery.  Indeed,  an 
important  effect  of  bringing  computers  into  the  building  delivery  process  is 
the  anticipated  improvement  in  buildings  themselves,  brought  about  by  better 
organizing  information  required  in  the  solution  of  complex  building  problems. 

A recent  study  of  computer-aided  design  for  Federal  agencies  concluded  that 
computers  enabled  designers  to  produce  better  buildings  [29]. 

C.2  INTEGRATED  CONSTRUCTION  PROJECT  INFORMATION 


Construction  projects  are  characterized  by  a large  number  of  participants 
(owners,  architects,  engineers  of  various  kinds,  regulatory  officials,  fabri- 
cators, etc.)  who  must  create,  use,  and  modify  a large  amount  of  interrelated 
data.  In  practice,  considerable  duplication  of  effort  typically  takes  place. 
In  preparing  shop  drawings,  for  example,  the  fabricator  often  repeats  the 
calculations  of  the  estimator,  who  repeated  the  calculations  of  the  designer. 
This  duplication  of  effort  is  expensive,  and  becomes  doubly  expensive  when 
errors  are  made  (a  seemingly  inevitable  occurrence).  The  use  of  a computer  as 
the  central  depository  for  all  data  describing  a single  project  would  greatly 
increase  productivity  by  minimizing  redundancy  and  opportunities  for  error, 
and  has  the  possibility  of  revolutionizing  construction  bid  preparation,  since 
all  competitors  could  work  from  identical,  certified  sets  of  material 
quantities . 

C.3  ECONOMIC  ANALYSIS  AND  LIFE  CYCLE  COSTING 


The  pre-design  planning  of  large  construction  projects  requires  careful 
analysis  of  potential  affects  of  the  construction  upon  surrounding  physical, 
social,  and  economic  systems  [14].  The  need  to  evaluate  construction  project 
life  cycle  costs  (LCC)  provides  additional  rationale  for  a computer-integrated 
construction  information  system.  LCC  analysis  is  a method  of  economic  evalua- 
tion of  alternative  project  plans  which  considers  all  relevant  costs  and 
benefits  associated  with  each  alternative  over  its  life  [57]. 

The  principal  steps  in  performing  an  LCC  analysis  include:  (1)  identifying 

alternative  design  solutions;  (2)  identifying  life  cycle  costs,  benefits,  and 
use  scenarios;  and  (3)  comparing  alternatives.  The  success  with  which  an  LCC 
analysis  will  be  accomplished  depends  upon  the  degree  of  detail  and  accuracy 
employed  in  describing  design  options,  life  cycle  costs  and  benefits,  and  upon 
the  correctness  of  scenarios  on  which  the  analysis  is  based.  Thus,  LCC  analyses 
are  highly  dependent  upon  up-to-date  and  well  organized  information,  and  are 
also  computationally  complex.  For  these  reasons,  they  tend  to  require  computer 
aids.  In  order  to  make  use  of  and  build  upon  available  project  data,  and  to 
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reduce  the  likelihood  that  costly  measures  will  be  duplicated,  it  is  imperative 
that  LCC  techniques  be  integrated  with  other  aspects  of  the  design  process 
which  affect  the  evaluation  and  selection  of  design  solutions. 

C.4  COMPUTER-AIDED  SPACE  PLANNING 


Computer-aided  space  planning  (CASP)  techniques  offer  certain  potential 
advantages  over  traditional,  manual  methods.  In  particular,  they  offer  speed, 
accuracy,  and  versatility.  Moreover,  because  CASP  enables  the  rapid  genera- 
tion of  a wide  variety  of  feasible  solutions,  and  because  in  some  cases  CASP 
techniques  operate  faster  as  the  problem  becomes  more  constrained,  CASP  may 
enable  designers  to  conduct  complex  conceptual  design  analyses  which  are  virtu- 
ally impossible  using  manual  methods  [28,  37].  An  inherent  feature  of  the 
building  design  process  is  that  decisions  which  critically  affect  building 
quality  and  life  cycle  cost  usually  occur  early  during  the  conceptual  design 
phase.  However,  less  than  20  percent  of  the  overall  design  manpower  and 
resources  usually  are  devoted  to  this  phase  of  a project  [28].  Consequently, 
CASP  offers  the  potential  to  greatly  improve  manpower  and  resource  effectiveness 
during  a critical  stage  of  the  design  process. 

However,  CASP  remains  the  rare  exception,  rather  than  the  rule,  in 
architectural  practice  today.  Incomplete  software  documentation,  hardware  and 
software  incompatibilities,  unavailability  of  software  packages,  and  unreliable 
or  incomplete  input  data  are  some  of  the  oft-cited  impediments  to  wider  CASP 
utilization  [28,  64].  These  impediments  are  typical  for  single-discipline  CAD 
development  within  so  broad,  complex  and  multi-disciplinary  an  enterprise  as 
the  building  delivery  process.  Indeed,  the  development  of  more  effective  CASP 
software  systems,  and  the  far  more  widespread  commercial  utilization  of  these 
sytems,  is  likely  to  benefit  from  large-scale  computer-based  integration  of 
the  construction  process. 

C. 5 COMPUTER-AIDED  REGULATORY  ACCEPTANCE 


One  of  the  frequent  complaints  heard  in  America  today  is  the  hidden  cost 
created  by  the  combination  of  regulatory  delays  and  inflation.  One  potential 
remedy  is  to  speed  the  review  of  plans,  specifications,  and  calculations  that 
must  be  performed  by  local  building  officials  preparatory  to  issuing  building 
permits.  The  task  of  regulatory  review  involves  checking  design  instances 
against  criteria  for  safety  and  serviceability,  and  hence,  is  directly  analo- 
gous to  constraint  processing,  discussed  earlier  in  this  report.  Computer- 
aided  regulatory  acceptance,  like  SI/CAD,  will  require  the  marriage  of 
automated  constraint  processing  and  computer-based  standards  representation 
technologies.  An  important  benefit  of  this  approach  concerns  the  opportunity 
for  building  officials  to  more  thoroughly  and  systematically  evaluate  designs 
against  ever-growing  and  more  sophisticated  requirements  in  building  codes 
without  adding  a large  number  of  technical  specialists  to  their  staffs,  thus 
reducing  the  need  to  increase  tax  revenues  or  fees  for  building  permits. 
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C.  6 OPERATING  AND  SAFETY  SYSTEMS 


During  the  life  of  a building  numerous  problems  arise  in  connection  with  both 
day-to-day  operations  (e.g.,  building  heating  and  cooling)  and  emergency  situa- 
tions (e.g.,  fire).  Computer  systems  often  are  installed  in  buildings  to  deal 
with  such  problems.  Frequently,  systems  installed  for  such  purposes  require 
continuous  or  intermittent  sampling  of  various  aspects  of  the  building  and  its 
environment,  and  conduct  comparisons  of  samples  against  baseline  or  other  data 
for  the  building.  Solution  techniques  for  operational  and  safety  problems  also 
may  involve  reviewing  previous  instances  of  similar  problems.  In  order  to 
facilitate  the  effectiveness  of  such  systems,  it  is  essential  that  integrated 
project  information  be  maintained  not  only  during  a building's  design  and 
construction,  but  throughout  its  life  as  well. 

It  is  clear  to  see  that  "computer-integrated  construction,"  as  briefly 
described  above,  is  an  expansion  of  the  ICAD  and  DICAD  concepts  introduced 
earlier  in  this  report.  It  is  also  clear  that  research  on  SI/CAD,  the  primary 
focus  of  this  report,  has  ramifications  for  aspects  of  building  delivery  lying 
beyond  computer-aided  structural  engineering.  The  importance  of  NBS  partici- 
pation in  research  concerning  the  general  area  of  computer-integrated 
construction  now  may  be  considered. 

C. 7 MEASUREMENT  TECHNOLOGY  FOR  COMPUTER  INTEGRATED  CONSTRUCTION 


In  the  jargon  of  artificial  intelligence,  building  delivery  requires  the 
solution  of  "ill-structured"  problems  [58],  and  even  of  "wicked"  problems  [10, 
25].  The  building  industry  has  much  to  gain  by  working  to  make  these  problems 
tractable  through  the  development  and  implementation  of  computer-integrated 
construction  technologies.  However,  industry  cannot  be  expected  to  bear  the 
full  cost  of  needed  fundamental  research.  Working  within  its  mission  as  the 
nation's  engineering  and  measurement  laboratory,  NBS  can  bring  considerable 
expertise  and  facilities  to  bear  on  identifying  and  characterizing  the  compo- 
nent parts  of  computer-integrated  construction  technology,  on  developing  the 
necessary  measurement  methods,  and  on  deriving  effective  performance 
requirements  for  future  (privately  developed)  hardware  and  software  products. 

C.7.1  Problem  Characterization 

While  each  element  of  computer-integrated  construction  has  specific  technical 
components,  there  are  a number  of  fundamental  issues  which  cut  across  these 
elements.  These  include  the  need  to:  (1)  evaluate  the  validity  of  analytical 

models,  algorithms,  and  interfaces  among  algorithms  which  comprise  computer- 
integrated  construction  software  systems;  (2)  ensure  the  portability  of  needed 
software  in  view  of  the  large  number  of  diverse  actors  and  systems  involved; 
and  (3)  facilitate  the  communication  of  information  among  diverse  actors  and 
systems  comprising  complex  building  projects. 

Analytical  models  underlying  algorithms  for  computer-aided  environmental 
analysis,  economic  analysis,  engineering  design,  and  functional  design  are 
extremely  complex  in  the  sense  that  they  frequently  contain  many  parameters 
which  interact  in  ill-defined  ways.  As  a result,  validating  models,  algorithms. 
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and  interfaces  itself  becomes  a difficult  task  requiring  basic  research.  But 
the  process  of  validation  is  seen  as  two-directional:  by  systematically 

adjusting  models  against  realworld  events,  the  analyst  also  obtains  a much 
deeper  understanding  of  the  nature  of  these  events. 

Because  complex  building  projects  involve  the  participation  of  numerous  diverse 
participants,  the  enchancement  of  construction  productivity  requires  that 
obstacles  to  communications  among  these  actors  be  minimized.  Such  communica- 
tions may  be  greatly  facilitated  through  the  implementation  of:  (1)  standard 

languages  for  developing  design  and  analysis  software;  (2)  standard  formats 
and  procedures  for  maintaining  project  information  databases;  and  (3)  software 
and  database  systems  which  are  portable  across  the  variety  of  computers  likely 
to  be  found  at  various  points  during  the  construction  process  (e.g.,  main-frames 
employed  during  large-scale  design  and  engineering  analysis;  graphics  devices 
and  word  processors  used  during  later  phases). 

C.7.2  Performance  Requirements 

To  be  effective  in  use,  the  performance  of  software  systems  applicable  to 
computer-integrated  construction  technology  must  be  properly  specified.  Per- 
formance requirements  for  these  systems  must  stipulate  measures  and  measure- 
ment methods  for  their  verification,  validation,  and  certification,  and  must 
serve  to  ensure  the  overall  reliability  of  the  software  (i.e.,  improving  the 
probability  that  a program  will  perform  its  intended  function,  with  minimal 
error,  over  some  period  of  time).  In  addition,  performance  requirements  are 
needed  to  specify  the  degree  to  which  the  design  or  construction  activity 
should  be  enhanced  or  made  more  productive  through  the  application  of  computer 
aids.  New  measures  will  be  needed  to  ascertain  such  performance,  as  well. 

Increasing  productivity  in  the  building  industry  will  require  a high  level  of 
portability  for  all  types  of  software  because  of  the  fragmented  nature  of  the 
construction  community  and  the  rich  variety  of  computer  hardware.  In  1975  it 
was  estimated  that  1,836  organizations  produced  software  for  civil  engineering 
applications  alone  [9].  The  same  study  questioned  the  value  of  much  of  this 
software,  in  terms  of  its  universal  transferability.  Since  that  time,  however, 
a significant  step  has  been  taken  with  the  introduction  of  a new  standard  for 
FORTRAN,  the  most  widely  used  language  in  the  engineering  design  field  [3]. 

Such  standards  provide  explicit  measures  of  portability  performance  of  individ- 
ual software  packages.  Other,  and  newer,  computer  programming  languages  and 
types  of  data  may  eventually  be  used  in  the  construction  industry,  and  similar 
measures  of  portability  performance  will  be  needed  when  they  appear. 

The  feasibility  of  an  integrated  project  information  system  to  maintain  the 
database  for  the  typical  construction  project  depends  to  a great  extent  on  a 
capability  to  measure  several  qualities  of  communications  performance  between 
those  actors  and  the  database  itself.  Similarly,  measures  of  the  quality  of 
communications  are  needed  for  evaluating  various  computer-aided  design  systems. 
All  these  communications  will  tend  to  be  dynamic,  changing  previously  stored 
information:  measures  of  the  efficiency  (speed  and  redundancy),  reliability 

(propagation  of  errors),  and  basic  format  for  data  handling  will  be  needed. 
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CBT  long  has  been  concerned  with  characterizing  and  measuring  critical  aspects 
of  buildings  which  affect  their  usefulness,  safety,  and  economy.  Other  com- 
ponents of  NBS  are  concerned  with  specifying  the  performance  of  software  and 
automation  systems.  The  characterization  of  elements  comprising  computer- 
integrated  construction  technology  and  the  specification  of  performance 
required  of  these  technologies  seem  well  within  the  grasp  and  mission  of  NBS 
research  teams. 
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